This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
Clearly I'm happy with what I already have. I've been working with the platform for nearly two decades now. Does that mean I don't want to see more being done? Of course not.
But you're deliberately constructing scenarios based on data model assumptions rather than business objectives. Look at your case study...
Employee (employee id = eid, lastname, firstname, birth date)
Department (department id = did, name)
DepartmentEmployees(did, eid)
Why would you need to implement a Domino solution with exactly the same data model? What business advantage do you gain? Is what you want to know "who are the employees in a given department?"
Well, that's easy. Even if you don't want to, say, put the department name in the employee record, you still might do something like put the department ID in the employee record. Then you have facilities like Xpages or Eclipse RCP components to resolve the department ID into a human-readable name.
If you had some reason to further abstract the relationship between an Employee ID and a Department ID, as in your example, then this is possible, too. There's nothing preventing you from defining, say, the UNID of the Employee document and the UNID of the Department document as their respective IDs. It's then incredibly easy to resolve these UNIDs to records from which you can retrieve human-readable values in Xpages. It's a bit more difficult in an Eclipse component, but definitely doable. I do this sort of thing all the time.
If you constantly define the problem in terms of data models, then sure, you'll experience nothing but limitations. If you define the problem in terms of functional objectives, then the data model becomes whatever you need to achieve that objective.
Making statements like "all applications have a relational component" is useless pedantry.
All this being said, I assure you that I have been chasing IBM with a pitchfork regarding replacement technology for the set of problems NSFDB2 was supposed to resolve. There are some important business objectives that still cannot be achieved in a timely fashion in the NSF architecture, and I regularly and repeatedly bring those up in the Design Partner program.
I can assure you that calling a category-defining architecture that has maintained two decades of success in a fiercely competitive marketplace "poor" is going to prevent anything else you say from being taken seriously by the people you're trying to reach.
Feedback response number WEBB7P2SLK created by ~Naomi Deskroterakol on 02/07/2009